Method and systems for providing merchant services with right-time creation and updating of merchant accounts

ABSTRACT

Systems and methods for providing merchant services with right-time creation and updating of merchant accounts. Merchant-specific information for each merchant is stored in a record and used to process purchase card transactions submitted by the merchant. When a user creates or updates a merchant account record, the user can indicate whether the update is to take effect immediately or at a user-specified later time. An immediate update is processed substantially without delay. Other updates are queued for later processing and processed at the user-specified later time.

CROSS-REFERENCES

This Application is a divisional of U.S. patent application Ser. No.10/245,789, filed Sep. 17, 2002, entitled “METHOD AND SYSTEMS FORPROVIDING MERCHANT SERVICES WITH RIGHT-TIME CREATION AND UPDATING OFMERCHANT ACCOUNTS”, which is hereby incorporated by reference in itsentirety for all purposes.

BACKGROUND

The invention relates generally to processing of purchase cardtransactions and in particular to methods and systems for providingmerchant services related to purchase card transaction processing.

A merchant who accepts purchase cards as payment for goods or servicesgenerally has an agreement with an acquiring bank for processing ofpurchase card transactions. As part of the agreement, the merchantmaintains an account at the acquiring bank for deposit and withdrawal offunds associated with the merchant's purchase card transactions.

Purchase cards are issued to cardholders by a variety of card issuers,including banks, retailers, or other financial service providers. In thecase of “interchange” cards, e.g., VISA or MASTERCARD card products,there is a card association that acts as an intermediary between theacquiring bank and the card issuer to complete a credit cardtransaction. (Rather than issuing cards itself, a card associationgenerally licenses other entities to issue cards under its brand name.)In the case of “private label” credit cards, e.g., credit cards issuedby a retailer, there is generally no intermediary; hence, such cards aregenerally accepted only by the issuing entity (or in some cases itssubsidiaries).

A typical purchase-card sales transaction begins when a cardholderpresents a purchase to a merchant in payment for goods or services. Themerchant transmits an authorization request to its acquiring bank. Inthe case of interchange cards, the acquiring bank typically does nothave direct access to information regarding cardholder account status,so the acquiring bank forwards the request to the appropriate cardassociation for authorization.

If the transaction is authorized, an authorization code is returned tothe merchant. The merchant completes the sales transaction with thecardholder by delivering the goods or services and obtaining in exchangea ticket representing the cardholder's agreement to pay the card issuer.The ticket is typically a piece of paper (usually signed by thecardholder) or an electronic equivalent. The ticket provides sufficientinformation to identify the cardholder, the card used, the merchant, andthe amount of the transaction.

Next, the merchant collects payment for the transaction by presentingthe ticket to the acquiring bank. Typically, the merchant accumulatestickets from a number of transactions (e.g., all transactions from oneday) and presents a batch of tickets together to the acquiring bank. Theacquiring bank acquires the ticket and deposits funds into themerchant's account. In general, the amount of funds deposited into themerchant's account is less than the amount of the sales transaction by apercentage (the “discount rate”) established between the merchant andthe acquiring bank. The acquiring bank may also maintain a reserveagainst the merchant account by temporarily withholding part of thefunds in order to cover the risk that the acquiring bank is notsubsequently repaid by a card issuer for any of the merchant'stransactions. Funds held in reserve are usually released to the merchantaccount after some period of time.

The acquiring bank presents the ticket to the card issuer forsettlement. Settlement requests may be processed in batches and may berouted through a card association rather than being sent directly to thecard issuer. The card issuer transfers funds to the acquiring bank inexchange for the ticket. The amount of funds transferred is, in general,less than the amount of the sales transaction because the card issuerdeducts an “interchange fee” reflecting the delay between the cardissuer's payment to the acquiring bank and the cardholder's payment tothe card issuer, as well as any costs associated with use of a cardassociation's interchange services. At some point after settlement, thecard issuer bills the cardholder for the full amount of the transaction,and the cardholder pays the card issuer according to the terms of theiragreement.

For a transaction where a private label credit card is used, theprocessing is similar, except that the acquiring bank and the cardissuer are generally the same entity. Thus, the acquiring bank is ableto authorize the transaction, and settlement between the card issuer andthe acquiring bank is not required. As is generally known, acquisitionand settlement processing may have many other variations, depending onthe card product used and the card acceptance policies adopted byvarious card issuers and associations (e.g., some card associationssettle directly with the merchant and do not transfer funds to theacquirer).

Acquiring banks are thus confronted with considerable complexity inmanaging purchase card operations, particularly when the bank providescard processing services for a large number of merchants who accept avariety of card products of different card associations and/or issuers.Transactions must be received and routed, and accounting of debits andcredits of funds during acquisition and settlement must be maintained.Information for each merchant must be kept up-to-date. Periodic accountstatements and other activity reports must be generated and sent to eachmerchant. Further, an acquiring bank may outsource some or all of itsmerchant processing operations to a third-party provider of merchantprocessing services. These third-party providers confront an added levelof complexity because of the need to manage data and transactions formultiple acquiring banks.

Existing systems generally rely on batch processing to perform allmerchant processing functions, including monetary transactions (e.g.,acquisition and settlement) and non-monetary transactions (e.g., openingand closing merchant accounts, changing merchant account terms, andupdating merchant contact information). In batch processing, transactionrequests are received by the acquiring bank or third-party merchantservices provider and accumulated for periodic processing, e.g., onceper day. Until the batch is processed, the transaction remainsincomplete, and information related to the transaction is generallyunavailable to merchants or acquiring banks. Moreover, any errors in thebatch cannot be corrected until the next batch update cycle. Thus, batchprocessing limits the ability of acquiring banks or third-partyproviders to provide merchant processing services in real time; amerchant may have to wait a day or more for a desired change, such asthe ability to accept a new type of credit card, to take effect.

Hence, it would be desirable to provide reliable and efficient merchantprocessing systems that can be used to manage merchant services moreeffectively.

SUMMARY

Embodiments of the present invention provide systems and methods forproviding merchant services with “right-time” creation and updating ofmerchant accounts. Merchant-specific information for each merchant isstored in a record and used to process purchase card transactionssubmitted by the merchant. When a user creates or updates a merchantaccount record, the user can indicate whether the update is to takeeffect immediately or at a user-specified later time. An immediateupdate is processed substantially without delay. Other updates arequeued for later processing. In some embodiments, an update affecting anumber of merchants can be processed in response to a single userrequest, and in other embodiments, updates to a number of differentinformation-containing fields for a merchant can be performed with asingle user request. Such systems and methods can enable an acquirer ora third-party provider of merchant services to respond more effectivelyto requests from merchants and to manage its data entry tasks in a moreefficient manner.

According to one aspect of the invention, a method for providingpurchase card transaction processing services to a plurality ofmerchants is provided. A merchant account record is associated with eachmerchant. The merchant account record includes a plurality of fields forstoring merchant-specific information. The merchant account record forone of the merchants is updated by processing a non-monetarytransaction. Processing the non-monetary transaction includesidentifying the merchant account record to be updated and receivinginput data from a user. The input data includes information identifyingwhich of the plurality of fields is to be updated and new data to bestored in the identified field. The user also provides an effective dateon which the identified field is to be updated. The effective date cancorrespond to either immediate updating or updating at a subsequentscheduled time selected by the user. Upon receiving an effective datecorresponding to immediate updating, the identified field is updated tostore the new data, substantially without delay. Upon receiving aneffective date corresponding to updating at a subsequent scheduled time,the input data are queued in association with the effective date in aneventing queue. The eventing queue is automatically and periodicallychecking the eventing queue to determine whether the effective date hasarrived; when the effective date has arrived, the identified field isupdated to store the new data. Subsequently, the merchant-specificinformation from the updated merchant account record is used to processa monetary purchase card transaction submitted by the merchant. Prior toqueuing the input data in the eventing queue or updating the merchantrecord, one or more edit checks can be performed to detect a conflictbetween the input data and reference data, such as data in another fieldof the merchant record or data relating to industry rules. When aconflict is detected, a user can be notified. Prior to queuing the inputdata in the eventing queue, the eventing queue can be checked to detecta previously entered pending update to the same merchant account record.When a previously entered pending update is detected, a user isnotified.

In some embodiments, a non-monetary transaction can be processed toupdate more than one of the plurality of merchant account records inresponse to a single user request. A group of merchant account recordsto be updated is identified from the single user request. Input data isreceived, including information identifying a field in each of the groupof merchant account records to be updated and new data to be stored inthe identified field. The identified field in each of the group ofmerchant account records is updated, either without substantial delay orat a subsequent scheduled time, with the input data specifying when theidentified field is to be updated. When the update is to occur at asubsequent scheduled time, the eventing queue may be used to cause theupdate to occur at the desired time.

In some embodiments, a non-monetary transaction can also be processed toupdate a plurality of fields in one of the merchant account records inresponse to a single user request.

According to another aspect of the present invention, a method forproviding purchase card transaction processing services to a pluralityof merchants is provided. A new merchant account record is created for anew one of the plurality of merchants. The new merchant account recordincludes a plurality of fields for storing merchant-specificinformation. One or more of the fields are populated with defaultvalues. Input data for at least one of the fields is received. Inresponse to a user request, the new merchant account record isactivated, thereby enabling the new merchant to submit purchase cardtransactions for processing. Activating the new merchant account recordis performed either substantially without delay upon receiving the userrequest or at a subsequent scheduled time. The merchant-specificinformation from the new merchant account record is then used to processa monetary purchase card transaction submitted by the new merchant. Theuser request can specify whether the activation of the new merchantaccount record is to be performed substantially without delay or at asubsequent time selected by the user. When input data for one of thefields is received, an edit check can be performed to detect a conflictbetween the input data and reference data, such as data in another fieldof the merchant record or data reflecting industry rules. When aconflict is detected, a user can be notified.

In some embodiments, merchant information files are generated from themerchant account records, and during processing of a monetary purchasecard transaction, merchant-specific information is obtained by accessingan updated merchant information file. In these embodiments, generationof a merchant information file for a particular merchant can happeneither without substantial delay upon a user request or at a scheduledtime.

In some embodiments, during transaction processing, a ticket record iscreated in a ticket data store using the transaction data for themonetary purchase card transaction. The ticket record includes ticketstatus information that is updated to reflect a current status ofprocessing of the purchase card transaction.

In some embodiments, the merchant-specific information for a merchantincludes a plurality of account identifiers, each account identifierassociated with at least one of a plurality of usage codes. Duringprocessing of a monetary purchase card transaction for which funds areto be transferred to the merchant, one of the plurality of usage codesis selected, and the account identifier associated with the selectedusage code is used to identify the merchant account to which funds areto be transferred.

In some embodiments where the acquirer reimburses the merchant for amonetary purchase card transaction, the merchant-specific information isalso used to determine whether the merchant participates in a reserve.If the merchant participates in a reserve, a reserve adjustment amountis deducted from the reimbursement amount and transferred to a reserve;the remainder is transferred to the merchant account.

According to another aspect of the invention, a system for providingpurchase card transaction processing services to a plurality ofmerchants is provided. The system includes a data store having amerchant account record associated with each of the plurality ofmerchants, each merchant account record including a plurality of fieldsfor storing merchant-specific information. To process a non-monetarytransaction to update a merchant account record associated with amerchant, the system includes control logic configured to identify themerchant account record to be updated and to receive input dataincluding information identifying which of the plurality of fields is tobe updated, new data to be stored in the identified field, and aneffective date on which the identified field is to be updated, where theeffective date corresponds to either immediate updating or updating at asubsequent scheduled time. Additional control logic is configured toupdate the identified field to store the new data substantially withoutdelay upon receiving an effective date corresponding to immediateupdating or to queue the input data in an eventing queue upon receivingan effective date corresponding to updating at a subsequent scheduledtime. Additional control logic is configured to automatically andperiodically check the eventing queue to determine whether the effectivedate has arrived and to update the identified field to store the newdata when the effective date has arrived. The system also includescontrol logic configured to process a monetary purchase card transactionsubmitted by the merchant using the merchant-specific information fromthe updated merchant account record.

According to another aspect of the invention, a system for providingpurchase card transaction processing services to a plurality ofmerchants is provided. The system includes control logic configured tocreate a new merchant account record for a new one of the plurality ofmerchants, the new merchant account record including a plurality offields for storing merchant-specific information. The system alsoincludes control logic configured to populate at least one of the fieldswith respective default values and control logic configured to receiveinput data for at least one of the fields. The system also includescontrol logic configured to activate the new merchant account record inresponse to a user request, thereby enabling the new merchant to submitpurchase card transactions for processing. Activating the new merchantaccount record is performed either substantially without delay uponreceiving the user request or at a subsequent scheduled time. The systemalso includes control logic configured to use the merchant-specificinformation from the new merchant account record to process a monetarypurchase card transaction submitted by the new merchant.

The following detailed description together with the accompanyingdrawings will provide a better understanding of the nature andadvantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a merchant processing systemaccording to an exemplary embodiment of the present invention;

FIG. 2 is a simplified block diagram of a merchant master databaserecord according to an embodiment of the present invention;

FIG. 3 is a simplified block diagram of a merchant hierarchy accordingto an embodiment of the present invention;

FIG. 4 is a flow chart of an exemplary process for processing anon-monetary transaction according to the present invention;

FIG. 5 is a flow chart of a second exemplary process for processing anon-monetary transaction according to the present invention;

FIG. 6 is a flow chart of an exemplary process for creating a newmerchant account according to the present invention;

FIG. 7 is a flow chart of an exemplary process for authorizing amerchant monetary transaction according to the present invention;

FIG. 8 is a flow chart of an exemplary process for ticket acquisitionaccording to the present invention;

FIG. 9 is a simplified block diagram of a ticket database recordaccording to an embodiment of the present invention;

FIG. 10 is a flow chart of an exemplary process for posting a deposit toa merchant account according to the present invention; and

FIG. 11 is a flow chart of an exemplary process for generating merchantcorrespondence according to the present invention.

DETAILED DESCRIPTION

The present invention provides improved merchant processing systems andmethods that may be used by acquiring banks or third-party providers ofmerchant processing services to process purchase card transactions. Insome embodiments, the system may provide improved efficiency and betterservice by reducing delays associated with updates to merchantinformation.

FIG. 1 is a simplified block diagram of a merchant processing platform100 according to an embodiment of the present invention. Merchantprocessing platform 100 operates to provide merchant processing servicesfor one or more acquiring banks. In one embodiment, merchant processingplatform 100 is under the control of an acquiring bank; in anotherembodiment, merchant processing platform 100 is under the control of athird-party provider and is used to provide merchant processing servicesfor one or more acquiring bank clients of the third-party provider.

Merchant processing platform 100 includes a server 105, which may be asingle computer or a plurality of networked computers. In general,server 105 manages updating of merchant information, processing ofindividual transactions, and reporting of merchant account activity aswill be further described below. Various operations of server 105 may beautomated; for instance, settlement of a batch of tickets may beautomatically initiated on a daily basis. It will be appreciated bypersons of skill in the art that where server 105 is implemented as aplurality of computers, the various functions of server 105 may beassigned to various ones of the computers in any suitable manner.

Server 105 accesses various databases including a merchant masterdatabase 110 and a ticket database 115. Merchant master database 110provides centralized storage of merchant-specific information needed toprocess transactions for a particular merchant. The content,organization, and updating of merchant master database 110 will befurther described below. Ticket database 115 contains informationregarding individual credit card transaction tickets, as describedfurther below. In the embodiment shown, server 105 also accesses aprogram library 120 that houses computer-executable instructions forperforming various merchant processing functions. Server 105 may beconfigured to execute various programs from library 120 automatically(e.g., on a periodic basis) or in response to user commands received viaan internal user interface 125.

Internal user interface 125 enables authorized personnel (generally,persons affiliated with the acquiring bank or third-party provider) tointeract with server 105 to perform functions including executingprograms from library 120, updating merchant master database 110 andticket database 115, and updating program library 120. Internal userinterface 120 may include hardware or software security components(e.g., password authentication) to prevent unauthorized use. Internaluser interface 125 includes a display device for presenting informationto a user, e.g., a computer monitor 126, and a user input device foraccepting input from a user, e.g., a keyboard 127. A user may accessinternal user interface 125 directly or via any suitable networkconnection, e.g., via leased lines, telephone lines, virtual privatenetworks, or the Internet.

In some embodiments, platform 100 is configured to process private labelcredit card transactions, in which case platform 100 may also include acardholder database 130.

Platform 100 communicates with various external components to performmerchant processing functions. In the embodiment shown, platform 100communicates with one or more merchants 140; one or more cardassociations 142, e.g., VISA or MASTERCARD; and an electronictransaction clearinghouse 145, e.g., the Federal Reserve AutomatedClearinghouse (ACH) system. In some embodiments, platform 100 may alsocommunicate with one or more acquiring banks 150.

An external user interface 155 may also be provided to allow directaccess to information contained in server 100 by merchants 140 and/oracquiring banks 150. Like internal user interface 125, external userinterface 155 may be implemented with hardware or software securitycomponents (e.g., password authentication) to prevent unauthorized use.In general, external user interface 155 is more limited than internaluser interface 125 with regard to allowed operations. For instance,external user interface 155 is preferably limited to viewing data frommerchant master database 110 and ticket database 115. When external userinterface 155 is provided, merchants 140 and/or acquiring banks 150 mayobtain information about the status of transactions directly, i.e.,without going through an intermediary who has access to internal userinterface 125.

Communication between platform 100 and the various external componentsmay take place over a variety of networks, including leased lines,telephone lines, virtual private networks, or the Internet. Hardwareand/or software-based security components (not shown) such as firewallsand data encryption systems may also be provided.

It will be appreciated that the description of platform 100 isillustrative and that platform 100 and its associated functionality canalso be implemented using more or fewer components than those describedherein. Based on the disclosure and teachings provided herein, a personof ordinary skill in the art will recognize other ways and/or methodsfor implementing the present invention.

Further aspects of platform 100 including exemplary processing methodsare described below. Section I describes an exemplary embodiment of amerchant record in merchant master database 110. Section II describes ahierarchical structure that may be advantageously used to organizemerchant records stored in merchant master database 110. Section IIIdescribes exemplary methods for updating merchant records stored inmerchant master database 110, including adding a new merchant record.Section IV describes processing of merchant credit card transactionsusing platform 100, including ticket database 115. Section V describesreporting and data access features of platform 100, including flexiblerouting of correspondence to various addresses, viewing of ticketinformation in real time; and a secure World Wide Web interfaceembodiment of external user interface 155. While platform 100 isreferred to as an example throughout the disclosure, it will beappreciated that the methods described below may be implemented usingother systems, and that variations and modifications of platform 100 arepossible. Further, while the examples below generally describe platform100 as being under the control of a third-party provider, it is to beunderstood that similar methods could be practiced with platform 100under the control of an acquiring bank or other acquirer.

I. Merchant Master Database Record

Merchant master database 110 includes a record related to each merchantfor whom processing services are provided by platform 100. Merchantmaster database 110 is used by various merchant processing applications,examples of which will be described below. In an exemplary embodiment,merchant master database 110 is maintained by an acquirer or by athird-party provider. Optionally, a merchant may be authorized to updatecertain fields of its own record directly.

An embodiment of a merchant record 200 in merchant master database 110is shown in FIG. 2. The information in merchant record 200 is organizedinto a number of sections, each containing one or more fields. Generalinformation section 205 includes the merchant's name and contactinformation, including address(es) and telephone number(s) for themerchant. General information section 205 also includes a merchantidentifier, which may be a number or alphanumeric code that uniquelyidentifies the merchant record 200.

Preferably, general information section 205 can include multipleaddresses associated with a particular merchant. Each address hasassociated with it one or more usage codes, as shown in section 205. Theusage code(s) associated with an address indicate the type(s) ofcorrespondence that is (are) to be sent to that address. For instance,in one embodiment, a usage code of “7” may correspond to the monthlystatement of the merchant account, a usage code of “2” may correspond tonotices of changes in account terms, and so on. For a particularmerchant, usage code “7” may be associated with address “1” (themerchant's corporate headquarters) and with address “2” (its outsideaccountant), while usage code “2” may be associated only with address“1.” For this example, monthly account statements are sent to both ofaddresses “1” and “2” while notices of changes in terms are sent only toaddress “1.” Other usage codes and other combinations of usage codes andaddresses are also possible. Further description of an addressmanagement technique suitable for use with merchant master database 110is provided in U.S. patent application Ser. No. 10/119,205, “System andMethod for Managing Account Addresses,” filed Apr. 8, 2002, which ishereby incorporated herein in its entirety for all purposes.

Merchant record 200 also contains income information section 210. Thisinformation relates to charges that the acquirer may impose against themerchant account. For instance, the discount rate (a percentage deductedfrom the value of each ticket before forwarding funds to the merchant)associated with the merchant may be included as a field in section 210.Additionally, the acquirer may impose other fees; for instance, in theembodiment shown, income information section 210 includes fields for amonthly account maintenance fee, purchase prices for various items ofcredit card processing equipment such as point-of-sale terminals orcharge slip imprinters, fees for customer service activity (which may bebilled to the merchant, e.g., on a per-call basis). It will beappreciated that these fields are merely illustrative and that the feescharged to a merchant may be varied.

Income information section 210 may be used to compute amounts to bededucted from the merchant account. For instance, during processing of asales transaction (described in more detail below), the discount ratemay be retrieved from merchant record 200. Likewise, customer servicecharges, monthly charges, equipment charges, and the like may becomputed and debited to the merchant account by a regularly occurringprocess that determines the appropriate fees by accessing merchantrecord 200.

Merchant record 200 also includes expense information section 215, whichreflects the costs to the acquirer of providing the merchant account.Fields in expense information section 215 generally correspond to thefields in income information section 210, but the data entered in eachfield may be different. The amounts entered in each field of expenseinformation section 215 generally reflect any charges that the acquiringbank pays to vendors or service providers, plus appropriate overhead. Anacquirer may use information from income section 210 and expenseinformation section 215 together for assessing merchant profitability.

Merchant record 200 also includes industry information section 220. Inthe embodiment shown, industry information section 220 includes fieldsfor identifying the card products that are accepted by the merchant(e.g., VISA products, MASTERCARD products, private label card products).Accepted card products may be identified by alphanumeric codes or othersuitable means. Examples of suitable techniques for defining and usingcard acceptance information is described in detail in U.S. patentapplication Ser. No. ______ (Attorney Docket No. 020375-006000US), whichis hereby incorporated herein in its entirety for all purposes. Othertechniques can also be used. Industry information section 220 alsoincludes information about the type of goods or services sold by themerchant (e.g., clothing retailer, grocery store), which may berepresented using a coding scheme such as the well-known StandardIndustrial Classification (“SIC”) codes or North American IndustryClassification System (“NAICS”) codes, as well as the media by which themerchant is authorized to conduct sales (e.g., in-store, mail-order,telephone-order, and/or Internet). If the merchant is a chain outlet,that information may also be included in a field in section 220, forinstance via a chain identifier.

Industry information section 220 may also include information related tothe merchant's participation in a reserve. More specifically, if theacquirer has chosen to maintain a reserve against the merchant accountto protect the acquirer against nonpayment by card issuers, the terms ofthe reserve may be specified. In some embodiments, the reserve fieldstores a reference to a computer program used to manage the reserve, aswill be described further below. Additionally, industry informationsection 220 may include fields for information related to the merchant'sparticipation in various discount or rewards/incentive programs that maybe offered by the acquirer, card associations, or other vendors.

Industry information section 220 may be used during transactionprocessing, for instance, to verify that the merchant is authorized toaccept the card product presented by the cardholders. In addition, anacquirer may use data contained within industry information section 220in pricing the merchant account. For instance, a first merchant whoaccepts credit cards for mail order or Internet transactions may exposethe acquirer to a higher risk of nonpayment than a second merchant whoconducts only in-store sales; the acquirer may price the first merchantaccount correspondingly higher. Industry information section 220 mayalso be used in various reporting applications. For example, if amerchant is a chain outlet, the merchant's purchase-card activity may berolled up with purchase-card activity of other merchants in the chainand reported to corporate headquarters at the chain level. As anotherexample, an acquirer may use data contained in industry informationsection 220 to analyze the performance (e.g., profitability) of itsmerchant account portfolio by type of business, by comparing merchantswho accept mail-order sales against merchants who do not, and the like.

Merchant record 200 further includes deposit account information section225. This section generally includes information needed to credit fundsto or debit funds from one or more deposit accounts maintained by themerchant at one or more banks. For instance, when merchant masterdatabase 110 is implemented in a processing system that uses the FederalReserve Automated Clearinghouse (ACH) system to perform electronic fundstransfers, the information for each deposit account includes a transitrouting number identifying a host financial institution for the accountand a demand deposit account number within that institution. In theembodiment shown in FIG. 2, a merchant record 200 may include more thanone deposit account number, thereby allowing the acquirer to direct aparticular electronic funds transfer transaction to one of severalaccounts held by the merchant. For instance, it may be desirable to havefunds deposited in a first deposit account and debits deducted from asecond deposit account. As will be described in more detail below, usagecodes associated with each deposit account identifier may be used tocontrol which transfer transactions use each deposit account. In oneembodiment, five usage codes are supported, corresponding to deposits,adjustments, discounts, debits, and monthly fees. Multiple usage codesmay be associated with the same deposit account so that a merchant isnot required to maintain multiple deposit accounts. It will beappreciated that any number of usage codes could be supported.

It will be appreciated that merchant record 200 is illustrative, andthat the content and arrangement of merchant-specific data can bevaried. Moreover, merchant master database 110 may be implemented usingany suitable database technology, for instance IBM's DB2 databaseproduct or other commercially available database products.

II. Merchant Hierarchy

Merchant records within merchant master database 110 may be organizedhierarchically for reporting or other purposes. An example of ahierarchical organization 300 is shown in FIG. 3. Each merchant 305corresponds to a merchant record in the merchant master database 110.Each merchant 305 is associated with an agent 310, each agent 310 with aprincipal 315, each principal 315 with a system 320, and each system 320with a client 325. The location of a particular merchant 305 may beindicated in the merchant master record 200 (FIG. 2) for the merchant.For instance, the merchant identifier may be a numerical identifierhaving an internal structure such that the first group of digitsindicates a client 325, the second group indicates a system 320, and soon.

In general, an agent 310 may represent any grouping of merchants 305that an acquirer or third party provider finds useful. Principals 315,systems 320, and clients 325 may each represent successively largergroupings of merchants 305. Reporting of account status and activity isprovided at each of the merchant, agent, principal, system, and clientlevels. Thus, hierarchy 300 may be used by an acquirer or third-partyservice provider to manage a large portfolio of merchant accountswithout implementing multiple merchant databases.

For example, in some embodiments, a third party service provider managesmerchant account portfolios for a number of acquirers and identifieseach acquirer as a different client 325. The intermediate levels of thehierarchy (system, principal, and agent) may be customized for eachacquirer to provide a reporting structure that the acquirer findsdesirable.

In one embodiment, one acquirer may define agents and/or principals torepresent various groupings of merchants. Other acquirers may use thevarious levels to sort merchants based on associations with smallaffiliate banks, sales territories, geographic regions or specific salespeople. Acquirers may also use the hierarchical structure to sortmerchants according to deposit or ticket submission methods used by themerchant (e.g., tape entered monetary batches, electronic enteredbatches and paper batches).

In some embodiments, not all levels of the hierarchy need be defined orused. For instance, an acquirer (client) may have merchants reportingdirectly under a principal or system. Where a structured merchantidentification number provides the hierarchical information, this can beimplemented by using a designated value (e.g., all zeroes) for a blockof digits to indicate an undefined level. Thus, in a particularimplementation, there will generally be at least one client and at leastone merchant; there may be any number (including zero) of systems,principals, and agents.

In some embodiments, hierarchy information about a merchant may be usedto control various aspects of transaction processing for that merchant.For instance, the system 320 within which a particular merchant 305resides may be used to determine where the merchant's tickets should berouted for authorization and/or settlement. As another example,hierarchy information may be used to determine when a batch oftransactions is submitted for settlement (e.g., batches from allmerchants identified with a particular system are processed beginning ata designated time each day).

It will be appreciated that the hierarchy presented here is an example,and that merchant processing systems may be implemented with otherhierarchies or with no hierarchy.

III. Updating the Merchant Master Database

In platform 100 of FIG. 1, “non-monetary” transactions can be performedto update records in merchant master database 110. As used herein, anon-monetary transaction refers generally to any update of a merchantrecord 200 in merchant master database 110 that does not result from apurchase card transaction. Examples of processing of non-monetarytransactions will now be described. These transactions may beimplemented using programs in program library 120 that may be invoked byan operator via internal user interface 125. The programs for processingnon-monetary transactions may include a security protocol to ensure thatthe particular operator invoking the program is authorized to modifymerchant master database 110.

An exemplary process 400 for processing a non-monetary transaction isillustrated in FIG. 4. Process 400 can be used to process anynon-monetary transaction, for instance, changing a merchant's address orchanging the discount rate applied to a merchant account. Process 400involves selecting a merchant record 200 (FIG. 2) to be updated andentering new data for a selected field in the record. Before thedatabase is updated, testing is performed to validate the newinformation. In addition, information regarding the updating process maybe recorded in an audit log.

At step 401, the operator selects a merchant whose record is to beupdated. For instance, the operator may enter a merchant identifier,navigate a merchant hierarchy displayed on the screen, or initiate asearch of merchant master database 110 using the merchant name or othermerchant information and select a merchant from the search result. Atstep 402, the merchant record 200 for the selected merchant isdisplayed. In some embodiments, merchant record 200 includes moreinformation than can be conveniently displayed at a single time, inwhich case the record is divided into screens and user controls (e.g.,keystrokes) for navigating among the screens are provided. Record datamay be divided among multiple screens in any suitable manner. At step403, the operator selects a field to be updated, for instance, the“discount rate” field. At step 404, the operator inputs new data for theselected field, for instance, a new discount rate of 4%.

At step 405, the transaction process performs one or more tests,referred to herein as “edit checks,” to determine whether the new datacreates a conflict. Conflicts may arise for various reasons, includingentry of an incorrect type of data for the field, as well as conflictswith other entries, with processing rules established for the merchantaccount (e.g., based on the system to which the merchant account isassigned), with applicable industry rules, or with governmentregulations. Each edit check detects a particular conflict.

For example, industry rules may require merchants to participate indifferent interchange programs (having different terms and conditions)depending on whether they are Internet merchants or traditional“brick-and-mortar” merchants. An edit check can be performed wheneverthe “interchange program” field is updated. This edit check looks at the“type of merchant” field to make sure that it contains a type qualifiedfor the selected interchange program. As another example, the selectedticket type for the merchant (e.g., tape entry, online entry, electronicentry) can be checked for consistency with entries in other fields sothat transactions can be processed properly.

If a conflict is detected, then at step 407 the update is rejected andthe operator is notified of the reason for rejection. In one embodiment,any conflict causes the process to return to step 404 to allow theoperator to enter new data. In an alternative embodiment, the operatoris prompted to select from “abort,” “edit,” or “proceed” options. If“abort” is selected, the transaction is aborted and no updates are made.If “edit” is selected, the process returns to step 404 to receive newdata. If “proceed” is selected, the process continues to step 406, wherethe merchant record is updated. For some types of conflicts, the“proceed” option may be disabled, e.g., where the proposed update wouldbe impossible or unlawful. Other prompts can also be implemented.

If no conflict is detected, then at step 406 the update is performed.Step 406 generally includes writing new data to the merchant record 200stored in merchant master database 110. If all processing jobs runningon platform 100 obtain merchant information directly from merchantmaster database 110, then the update will have essentially immediateeffect. In some embodiments, however, processing jobs running onplatform 100 do not access merchant records 200 directly; instead, thejobs access a data file (e.g., a Virtual Storage Access Method, or VSAM,file) for each merchant that is periodically (e.g., once per day)back-built from merchant records 200. In these embodiments, changes tothe merchant record 200 have no effect on processing until the nextback-build cycle.

To reduce or eliminate such delays, a “right-time” processing option maybe provided to enable the operator to initiate a near-immediate rebuildof the VSAM file for the merchant whose record has been updated. Therebuild occurs as soon as possible rather than waiting for the nextregular back-build cycle. The rebuild may be done by reading thenewly-updated merchant record 200 from merchant master database 110, orit may be executed directly from the entered data, in parallel with thedatabase update. It will be appreciated that “right-time” processing canalso be implemented as a default processing mode, thereby not requiringa specific operator request to initiate it.

An audit log may also be implemented to provide tracking of selectednon-monetary transactions. For instance, an acquirer or third-partymerchant services provider may designate non-monetary transactionsaffecting certain fields of a merchant record as “critical,” meaningthat details regarding any updates to those fields are to be logged.When an audit log is implemented, at step 408, the process determineswhether the updated field is one of the designated critical fields. Ifso, then at step 409 an audit log entry is created before the processends. The audit log entry includes information such as the date, theidentity of the operator who entered the update, the merchantidentifier, the field that was updated, and old and new data values.Audit log entries are stored either in the merchant record or in aseparate file or database. The entries are then used for reportingand/or review as described below.

The audit log may be viewed using a separate review program, which isalso invoked by an operator via internal user interface 125. The auditlog review program provides various ways to view records of criticalchanges. For instance, updates may be viewed by date, by merchant, byfield affected, and so on.

A second exemplary process 500 for processing a non-monetary transactionis illustrated in FIG. 5. This process supports entering updates thatare to take effect at a specified future date. Each “future” update isstored in an eventing queue managed by platform 100 as a pending updateuntil the specified future date arrives, at which time the affectedfield of the merchant record is updated.

Steps 501-504 are similar to steps 401-404. At step 505, the programprompts for an effective date, which may be either a future date or adate of “now,” meaning that the update is intended to take effectimmediately. Depending on implementation, the effective date may beentered in relative form (e.g., 60 days from today) or absolute form(e.g., Jan. 1, 2003); some implementations may support both modes.

At step 506, the process determines whether there are any previouslyentered pending updates to the selected field, e.g., by checking entriesin the eventing queue. If so, then at step 507, the operator is advisedof the pending update and prompted for instructions. In one embodiment,the operator may choose to cancel the previously entered change, cancelthe new change, keep both changes, or supersede all changes with a newvalue. Canceling the previously entered change causes the correspondingentry to be deleted from the eventing queue. Canceling the new changecauses process 500 to abort. Keeping both changes causes the process toproceed to step 508 without any effect on the previous entry.Superseding all changes causes the process to delete the pending updatefrom the eventing queue and return to step 504 to receive new data.

At step 508, edit checks are performed to determine whether the new datawill create any conflicts when it goes into effect. This step isgenerally similar to step 405 in FIG. 4. If a conflict is detected, thenthe operator is prompted at step 509 to address the conflict; this stepand the operator's options may be generally similar to step 407 in FIG.4.

At step 510, the update is stored or performed. If the effective date is“now,” an updating process similar to step 406 (including the“right-time” option) is performed to update the merchant record 200.

If the effective date of the update is in the future, then the update isstored as an entry in the eventing queue and processed when theeffective date arrives. In one embodiment, the eventing queue is aseparate file from the merchant record, and the entries in the queue mayinclude updates for a number of merchant records. Each entry in theeventing queue generally includes at least the effective date, themerchant identifier for the record to be updated, the field to beupdated, and the new value. A batch processing job checks the eventingqueue daily (or at other regular intervals); when the effective date ofa particular update arrives, the appropriate merchant record 200 inmerchant master database 110 is updated using the new value. Where VSAMor other back-built data files are used to provide merchant information,the eventing-queue processing job is advantageously implemented toexecute just prior to the back-build operation.

Logging of critical updates (steps 511 and 512) is performed in a manneranalogous to steps 408 and 409 of FIG. 4, and the log may be reviewed asdescribed above.

Process 500 may advantageously be used in a number of situations. Forinstance, an acquirer may decide to change an account fee, giving themerchant 30 days' notice. The update instruction may be entered at thetime the notice is delivered, with an effective date 30 days later.Thus, an operator need not remember to enter the change on the specifieddate. In addition, where it is known in advance that a change affectingmany merchants will occur on a given date, it is possible to beginentering update instructions well ahead of time.

It will be appreciated that processes 400 and 500 are illustrative, andthat modifications and variations are possible. In addition, processes400 and 500 may be used as a basis to implement further functionality,examples of which will now be described.

In some instances, multiple non-monetary transactions are intended totake effect concurrently for a particular merchant account. For example,closing a merchant account typically requires modifying a number offields in the merchant master record. In such instances, an “actiongrouping” may advantageously be defined to reduce the complexity ofmaking the modifications. In an action grouping, one or morenon-monetary transactions are performed as a single data entrytransaction.

For example, an action grouping may be used to close a merchant account.The user inputs a single instruction to close the account. Thisinstruction causes several non-monetary transactions to be generated,such as disabling automated clearinghouse functions and card acceptanceswitches so that further processing for the merchant cannot occur.

Action groupings are advantageously provided when a number ofnon-monetary transactions routinely need to be performed concurrently.In such cases, using an action grouping can reduce the risk of error(e.g., an operator forgetting to update one of the fields) and thenumber of operator actions required to implement a change. In addition,action groupings may be implemented so that edit checks take intoaccount the combined effect of all the grouped changes, therebyeliminating conflict messages that may occur during a sequence ofindividual updates to fields using process 400.

In other instances, the same non-monetary transaction needs to beentered for a number of merchants. For instance, if the U.S. PostalService changes a zip code, all merchant records with addresses affectedby the change must be updated. As another example, if a corporate ownerof a chain of retail stores adopts a new policy of accepting a certaincard product, all merchant records associated with the chain must beupdated to support acceptance of that card product. To facilitate dataentry in such cases, a “power entry” process is provided, in whichmultiple merchant records may be selected and the non-monetarytransaction entered for all selected records in one data entry process.The power entry process may be essentially similar to processes 400and/or 500, except that multiple merchants may be selected in the firststep. Groups of merchants may be selected based on one or moreaccount-level settings, such as industry classification (using, e.g.,SIC codes), mode of monetary transaction entry (e.g., paper, tape,electronic), location (e.g., zip code), sales territory, or any otherparameter provided by merchant record 200.

Creation of a new merchant account may be implemented as a series ofnon-monetary transactions, as shown in the exemplary process of FIG. 6.At step 601, a new (empty) database record 200 is created for themerchant. At step 602, hierarchy information is entered for the newrecord; for instance, the merchant is assigned to a client, system,principal, and/or agent. At step 603, default values are automaticallyentered into all fields for which default values have been previouslydefined. In one embodiment, any field may have a default value,depending on the preferences of the third-party provider or theacquirer. A default value may be defined globally, i.e., for all newmerchant accounts, or for accounts within a part of the hierarchy. Forinstance, the acquirer may establish a uniform statement fee or monthlyaccount maintenance fee applied to all merchants; these default valuesmay be set at the client level. In the case of chain merchants, defaultsfor a number of fields (e.g., corporate address information, acceptedcard products, mode of ticket submission, and type of business) may beestablished at the chain headquarters level. It will be appreciated thatproviding default values may reduce the manual data entry required toopen a new merchant account.

At step 604, an unpopulated field of the new merchant record 200 isselected. Selection may be performed manually by the operator creatingthe account, or the “open” process may be configured to select eachunpopulated field sequentially. At step 605, the process receives datafor the selected field. At step 606, edit checking is performed, anddetection of a conflict results in a rejection of the entry at step 607and a prompt to re-enter the data at step 605. Alternatively, editchecking may be performed only after data entry for all fields iscompleted. At step 608, the record is updated to reflect the entereddata. At step 609, it is determined whether more unpopulated fieldsremain. This determination may be made either by prompting the operatoror automatically. If unpopulated fields remain, the process returns tostep 604 to select another unpopulated field.

If no unpopulated fields remain, the new account is activated at step610. In embodiments where processing is done from VSAM files (or otherfiles) rather than directly from merchant database 110, it will beappreciated that the account is inactive until a VSAM file is built. Toprovide “right time” opening of new accounts, step 610 may includecausing a VSAM file for the new merchant to be built on request, so thatplatform 100 will be able to begin transaction processing for the newmerchant without delay. In an alternative embodiment, the VSAM file isbuilt in parallel with the database updating during steps 601-608.

Logging of activity associated with new account creation is not shown inprocess 600 but is optionally available. Implementation of an audit logmay be generally similar to that described above.

It will be appreciated that steps 606, 607, and 608 may be madeidentical to previously described steps 405 and 407. Thus, accountopening process 600 may be implemented to repeatedly invoke process 400for performing individual non-monetary transactions, with the merchantselection and field selection steps being performed automatically ratherthan having the operator manually perform the selections.

One skilled in the art will recognize that the foregoing processes aremerely examples, and that process steps may be modified or varied.

IV. Monetary Transaction Processing

Merchant processing platform 100 of FIG. 1 also performs processing ofmonetary transactions for merchants, which may include sales and returntransactions, payment transactions (where the cardholder makes a paymenton a credit card account at the merchant location), and cash advances,or other types of monetary transactions. In general, during suchprocessing, platform 100 requires various information specific to themerchant; according to embodiments of the present invention, thisinformation is obtained either from merchant records 200 in merchantmaster database 110 or from a merchant descriptor file (e.g., a VSAMfile) built from merchant record 200 as described above. Database 110and the descriptor files are kept up-to-date using the methods describedabove. In general, merchant records 200 may be used to provide merchantinformation as required to complete any monetary transaction.

For instance, FIG. 7 illustrates an exemplary process 700 for handlingan authorization transaction. Such transactions are typically submittedby a merchant when a cardholder presents a purchase card. At step 701,transaction data are received from a merchant. The data include amerchant identifier, a card number obtained from the purchase cardpresented by the cardholder, a transaction type (e.g., sale, cashadvance), and a transaction amount. At step 702, merchant masterdatabase 110 is accessed using the merchant identifier to determinewhether the merchant has a valid account. This may be determined in partby the presence or absence of a merchant record 200 for the merchant. Ifa merchant record 200 is not found, then the account is invalid and theauthorization is denied. If a merchant record 200 is found, the merchantrecord 200 is checked to determine whether the account is currentlyvalid or not.

If the account is valid, then at step 703, the merchant record 200 isagain used to determine whether the merchant is authorized to accept thecard product presented. In one embodiment, the card product presentedmay be determined from the credit card number in a manner known in theart, e.g., by reference to the first few digits of the card number.Process 700 checks merchant record 200 to determine whether this cardproduct is one that the merchant accepts. If platform 100 is unable toidentify the card product, or if it is determined that the merchant isnot authorized to accept the card product, the authorization is denied.Otherwise, the process proceeds to step 704, where the transaction typeprovided with the transaction data is verified. Again, data from themerchant master record 200 is used to determine whether the merchant isauthorized to accept transactions of the specified type. (For instance,a retailer may be authorized to accept a card association's cards forsales transactions, but not for payment transactions.) If thetransaction type is not authorized, the authorization is denied.Otherwise, at step 705 an authorization request is forwarded to anappropriate entity for authorization. The appropriate entity may bedetermined based on the card product and/or other information, such asthe system to which the merchant account is assigned. For instance, inone embodiment, if the card product is an association A card, theappropriate entity is association A. At step 706, a decision is returnedfrom the appropriate entity, which may be either an approval or adenial. In either case, the result is transmitted to the merchant.

It will be appreciated that process 700 is illustrative, and that stepsmay be modified or varied. In general, any sequence of authorizationsteps, a number of which are known in the art, may be used, with amerchant record 200 supplying the needed merchant-specific information200. In an alternative embodiment, authorization may be performed asdescribed in the above-referenced co-pending U.S. patent applicationSer. No. ______ (Attorney Docket No. 020375-006000US).

As another example, a ticket acquisition process using merchant masterdatabase 110 will now be described. As is known in the art, aftercompleting a transaction with the cardholder, a merchant presents atransaction ticket (or simply “ticket”) to the acquiring bank forpayment. Tickets may be presented in batch (e.g., all tickets for theday's transactions are presented at the end of the day) or in any othersuitable fashion. For some transactions (e.g., transactions usingelectronic debit networks), authorization and acquisition may occur atthe same time. Platform 100 performs automated ticket acquisition; anexemplary process is shown in FIG. 8. At step 801, the system receivesthe ticket data from the merchant. The ticket data may be received inpaper or electronic form; paper tickets may be converted to electronicform by any suitable methods, a number of which are known in the art.

At step 802, a ticket record (in ticket database 115) is created for theticket. An example of a ticket record 900 is shown in FIG. 9. The recordincludes the merchant identifier, transaction date, transaction type,transaction amount, and credit card number. The record may also includeadditional information, such as specific items purchased (in the case ofa sales transaction) or whether the transaction is subject to specialterms (e.g., 90 days same as cash). Industry-specific data elements maybe included, e.g., ticket itinerary information in the case of airlines,rental data in the case of auto rental agencies, check in/check outinformation in the case of hotels. The ticket record also includesstatus information indicating the progress of processing for the ticket.Information in the ticket database 115 is updated as tickets arereceived and processed. As described below, ticket database informationis viewable by acquirers.

In some embodiments, ticket records 900 may be created duringauthorization, including some or all of the ticket information. Theserecords may be matched to subsequently submitted tickets.

At step 803, the ticket is subject to further processing, details ofwhich depend on the particular implementation. For instance, furtherprocessing may include fraud or risk detection processes, sending theticket information to the appropriate destination (e.g., a cardassociation or another processor), sending the ticket into interchangequalification processing, settlement processing (i.e., exchange offunds), and similar processing steps known in the art. In someimplementations, steps 801 and 802 may be performed for an individualticket as a particular merchant-cardholder transaction is completed, inwhich case step 803 may include holding the received tickets for aperiod of time before performing further processing in batch. Statusinformation included in ticket record 900 is also updated as the varioussteps occur.

FIG. 10 illustrates a process for transferring funds to a merchantaccount during batch acquisition of sales tickets. In one embodiment,this process follows step 803. At step 1001, a ticket total isdetermined, either from the ticket database or from another store ofticket information. At step 1002, the applicable discount rate isdetermined from the merchant master database record. At step 1003, thenet deposit amount is determined by using the discount rate to reducethe ticket total. In some embodiments, steps 1001, 1002, and 1003 areperformed for an entire batch of tickets, and step 1001 includes summingthe transaction amounts for all tickets in the batch. In otherembodiments, steps 1001, 1002, and 1003 are performed for each ticket,for instance, if the discount rate can vary from one sales transactionto the next within a batch.

In some embodiments, automatic collection of a reserve against themerchant account is supported. Accordingly, at step 1004, it isdetermined whether the merchant participates in a reserve. Where theacquirer uses the automated reserve collection feature, the merchant issubjected to having a portion of its daily deposits held by the acquirerfor the purposes of mitigating risk. The reserve system may becontrolled at any hierarchical level so that all merchants or a subsetof merchants can be selected to participate. For instance, an acquirermay choose to require a reserve only for high-risk merchants and groupthose merchants together using hierarchy 300 as described above.

Using the automated reserve feature, the acquirer may hold a wholedollar amount or a percentage of the merchant's total deposits, for allcard products or only certain card products (e.g., the acquirer may holda 10% reserve against ticket amounts from transactions using interchangecard products and no reserve against ticket amounts from transactionsusing other card products).

Preferably, information regarding the applicable reserve rules iscontained in the merchant record 200. If there is a reserve, then atstep 1005, the applicable reserve deduction is computed. In someembodiments, the reserve is implemented by including in merchant masterrecord 200 (FIG. 2) a reference to program code that implements theappropriate reserve terms, and step 1005 includes executing thereferenced code. For example, the acquirer may be entitled to hold inreserve 10% of all deposits for a particular merchant, up to a maximumreserve of $50,000. In this example, at step 1005, the amount currentlyheld in reserve would be determined. In one embodiment, the totals heldin reserve are stored in separate files from the merchant record 200;these files are accessed at step 1005. Then 10% of the net depositamount computed in step 1003 is determined. Next, it is determinedwhether adding that amount to the current reserve would cause thereserve to exceed $50,000. If so, then the difference between thecurrent reserve and $50,000 is the reserve deduction. Otherwise, 10% ofthe net deposit amount is the reserve deduction. The net deposit amountis then adjusted by the reserve deduction. The reserve deduction amountis moved via Automated Clearinghouse (ACH) transfer (or other automatedfunds transfer) to a demand deposit account specified by the acquirer.Alternatively, the amount may be recorded as a general ledger entrywithout a funds transfer, or a report may be generated, on the basis ofwhich the acquirer can move the funds manually.

At step 1006, the merchant account to which funds are to be transferredis selected. The merchant account information is preferably stored inthe merchant record 200 (FIG. 2). In some embodiments, information formultiple merchant accounts may be included, with each account associatedwith one or more usage codes, as described above. Where usage codes arepresent, step 1006 includes selecting the account associated with theusage code corresponding to deposits. At step 1007, a deposit of the netdeposit amount, adjusted for reserve deductions where applicable, isposted. In some embodiments, the deposit is posted via ACH transfer. Theticket record in the ticket database may be updated with a statusindicator indicating that the merchant has been paid.

To reduce the number of funds transfer transactions, sums to betransferred can be accumulated for a batch of tickets and a singletransfer transaction generated at the end of the batch. Accumulationprocesses known in the art may be used. Similarly, amounts to betransferred to a reserve can also be accumulated for a batch of ticketsto further reduce the number of funds transfer transactions required.

Settlement with the card issuer is conducted after acquisition.Preparation of settlement requests may be implemented using knowntechniques. Ticket data may be obtained from ticket records 900 inticket database 115 or from another store of ticket data.

In one embodiment, ticket record 900 includes all information needed forsettlement of the transaction. In addition, it will be appreciated byone of skill in the art that a ticket record 900 may also be used toretrieve information about the original ticket during chargebackprocessing.

It will be appreciated that the foregoing processes are examples andthat process steps may be varied or combined. Similar processes may alsobe implemented to perform other transactions; for instance, processing atransaction that requires debiting a merchant account may involveselecting the appropriate merchant account to debit according to a usagecode in the merchant record 200. To obtain merchant-specifiedinformation, processing jobs may either access merchant records 200 inmerchant master database 110 directly or use merchant descriptor files,which may be implemented using VSAM file technology, to obtain merchantinformation. Because merchant records 200 and, if applicable, merchantdescriptor files can be updated on a right-time basis, as describedabove (Section III), information used in monetary transaction processingcan be more easily kept current.

V. Reporting and External Access to Data

Platform 100 of FIG. 1 may also be used to generate reports and othercorrespondence to be provided to merchants or acquiring banks. Inaddition, various information from merchant master database 110 andticket database 115 may be made available via external user interface155. Exemplary embodiments of reporting and data access functionalitywill now be described.

One aspect of generating a report or other correspondence is identifyingthe correct recipient. As described above, a merchant master databaserecord 200 (FIG. 2) may include multiple addresses associated with themerchant, and different addresses may be used for different types ofcorrespondence.

A process 1100 for selecting one or more recipients for a particulartype of correspondence is illustrated in FIG. 11. At step 1101, the typeof correspondence is identified. For instance, if a scheduled processruns to generate a monthly account statement, the process may beconfigured to select a usage code corresponding to monthly accountstatements. At step 1102, the process queries merchant record 200 foraddress(es) associated with the selected usage code and receives inresponse one or more addresses, for instance addresses of an outsideaccounting firm and the merchant's finance department. At step 1103, theprocess generates a copy of the correspondence to be sent to eachaddress received at step 1102. Thus, any type of correspondence may bedirected to one or more appropriate recipients. The content of thecorrespondence may be generated by any appropriate method, such aswell-known software for generating form letters or account activityreports. Processes for managing correspondence addresses are describedfurther in the above-referenced co-pending U.S. patent application Ser.No. 10/119,205.

The present invention also provides acquirers or merchants with accessto ticket records 900 contained in ticket database 115 via external userinterface 155 (FIG. 1). The information may advantageously be madeviewable without permitting updates or modifications. In one embodiment,a third-party provider manages ticket database 115, and an acquirerclient is able to access ticket information using acquirer-definedqueries. For example, the acquirer may request to view all of thetransactions that were processed for a specific type of merchant (e.g.,all auto-rental merchants) to determine profitability. The acquirer mayalso access specific transactions in order to comply with reportingrequirements established by various card associations or issuers.

Additionally, access to merchant data or ticket database data can beprovided via the World Wide Web. Secure transmission of data can beprovided using known security software, and a graphical user interfacemay be implemented using conventional software such as First DataMerchant Services' eMerchantView^(SM) product and/or IBM'sWebsphere^(SM) product, or other products. In addition, the sameinterface may be used for internal user interface 125 to performdatabase updates. Using World Wide Web technology can simplify the taskof providing data access to merchants, acquirers, or other parties atremote locations.

While the invention has been described with respect to exemplaryembodiments, one skilled in the art will recognize that numerousmodifications are possible. For instance, an acquirer may outsourcevarious combinations of its merchant processing activities to athird-party services provider; in such cases, a plurality of platformswill generally be used for merchant processing. Some of the platformsmay be controlled by the acquirer while others are controlled by thethird-party services provider. Similarly, the merchant master databaseand/or ticket database may be implemented as multiple databasescontaining subsets of the data. In addition, the present invention maybe implemented using any combination of software and/or hardware.Moreover, while the invention has been described with reference tocredit card or purchase card transactions, one of ordinary skill in theart will recognize that the invention may also be used for processingmerchant transactions involving other types of non-cash paymentinstruments, e.g., debit cards or electronic checks.

Thus, although the invention has been described with respect toexemplary embodiments, it will be appreciated that the invention isintended to cover all modifications and equivalents within the scope ofthe following claims.

1. A system for providing purchase card transaction processing servicesto a plurality of merchants, comprising: a data store having a merchantaccount record associated with each of the plurality of merchants, eachmerchant account record including a plurality of fields for storingmerchant-specific information, at least a portion of themerchant-specific information relating to merchant direct accessauthorization, wherein each merchant account record is associated witheach of the plurality of merchants using a merchant financial accountrecord system, the merchant financial account record system beingmanaged at least in part by an entity which provides purchase cardtransaction processing services to the merchant; control logicconfigured to process, using the merchant financial account recordsystem, a non-monetary transaction to update the merchant account recordassociated with one of the plurality of merchants, including: controllogic configured to identify the merchant account record to be updated;control logic configured to receive input data including informationidentifying which of the plurality of fields is to be updated, new datato be stored in the identified field, and a request for immediateupdating of the identified field; control logic configured to update theidentified field to store the new data substantially without delay uponreceiving the request; a user interface, in operative communication withthe merchant account record system and configured to: receive, from arequesting merchant, a request for direct access to a requested recordportion of at least one of the merchant account records, wherein therequesting merchant is one of the plurality of merchants, and therequested portion comprises the updated identified field; verify, usingthe merchant direct access authorization, whether the requestingmerchant is authorized to view the requested record portion; and wherethe requesting merchant is authorized, grant access to the requestingmerchant to the requested record portion; and control logic configuredto process a monetary purchase card transaction submitted by themerchant using the merchant-specific information from the updatedmerchant account record.
 2. The system of claim 1, further comprising:control logic configured to generate an updated merchant informationfile from the updated merchant account record, wherein the control logicconfigured to process a monetary purchase card transaction is furtherconfigured to access the merchant information file to obtain themerchant-specific information.
 3. The system of claim 1, wherein thecontrol logic configured to process a non-monetary transaction furtherincludes: control logic configured to detect a conflict between theinput data and reference data and to notify a user when a conflict isdetected.
 4. The system of claim 3, wherein the reference data is datain another field of the merchant account record.
 5. The system of claim3, wherein the reference data is data relating to industry rules. 6.(canceled)
 7. The system of claim 1, further comprising: control logicconfigured to create a new merchant account record for a new one of theplurality of merchants; control logic configured to populate at leastone of the fields in the new merchant account record with respectivedefault values; control logic configured to receive input data for atleast one of the fields; control logic configured to activate the newmerchant account record in response to a user request, thereby enablingthe new merchant to submit purchase card transactions for processing,wherein activating the new merchant account record is performed eithersubstantially without delay upon receiving the user request or at asubsequent scheduled time.
 8. The system of claim 7, wherein the userrequest specifies when the activation of the new merchant account is tobe performed.
 9. The system of claim 7, further comprising: controllogic configured to generate a new merchant information file from therespective default values and the input data, wherein during processingof monetary purchase card transactions for the new merchant, themerchant-specific information is obtained by accessing the new merchantinformation file.
 10. The system of claim 1, further comprising: controllogic configured to process a non-monetary transaction to update morethan one of the plurality of merchant account records in response to asingle user request, including: control logic configured to identifyfrom the single user request a group of merchant account records to beupdated; control logic configured to receive input data includinginformation identifying a field in each of the group of merchant accountrecords to be updated and new data to be stored in the identified field;and control logic configured to update the identified field in each ofthe group of merchant account records, either without substantial delayor at a subsequent scheduled time, wherein the input data specifies whenthe identified field is to be updated.
 11. The system of claim 1,further comprising: control logic configured to update a plurality offields in one of the merchant account records using predetermined newdata in response to a single user request.
 12. The system of claim 1,wherein the control logic configured to process a monetary purchase cardtransaction includes: control logic configured to receive transactiondata for the monetary purchase card transaction from the merchant, thetransaction data including a purchase card identifier and a transactiontype identifier; control logic configured to determine from themerchant-specific information whether the merchant is authorized toaccept a purchase card corresponding to the purchase card identifier;control logic configured to determine from the merchant-specificinformation whether the merchant is authorized to submit transactions ofa type corresponding to the transaction type identifier; and controllogic configured to route the transaction to a routing destination. 13.The system of claim 12, further comprising: a ticket data store having aticket record for each of a plurality of tickets; control logicconfigured to create a new ticket record in the ticket data store usingthe transaction data received from the merchant; and control logicconfigured to add ticket status information to the new ticket record,wherein the ticket status information is updated to reflect a currentstatus of processing of the purchase card transaction.
 14. The system ofclaim 12, further comprising: control logic configured to determine anet deposit amount from the transaction data; and control logicconfigured to transfer funds corresponding to the net deposit amount toa merchant account for the merchant, wherein an identifier of themerchant account is included in the merchant-specific information forthe merchant.
 15. The system of claim 14, wherein: the merchant-specificinformation for the merchant includes a plurality of accountidentifiers, each account identifier associated with at least one of aplurality of usage codes; and the control logic configured to transferfunds is further configured to select one of the plurality of usagecodes and to use the account identifier associated with the selectedusage code to identify the merchant account to which funds correspondingto the net deposit amount are to be transferred.
 16. The system of claim14, wherein the control logic configured to determine a net depositamount from the transaction data includes: control logic configured todetermine a transaction total from the transaction data and to reducethe transaction total according to a discount rate, thereby generatingan adjusted transaction amount; and control logic configured todetermine from the merchant-specific information whether the merchantparticipates in a reserve and, upon determining that the merchantparticipates in a reserve, to reduce the adjusted transaction amount bya reserve adjustment amount, wherein the net deposit amount is equal tothe adjusted transaction amount when the merchant does not participatein a reserve and the net deposit amount is equal to the reduced adjustedtransaction amount when the merchant does participate in a reserve. 17.The system of claim 12, further comprising: control logic to determine atransaction total from the transaction data; control logic to determinea discount rate from the merchant-specific information; and controllogic to compute a net deposit amount by reducing the transaction totalaccording to the discount rate.
 18. The system of claim 17, furthercomprising: control logic to determine from the merchant-specificinformation whether the merchant participates in a reserve; and controllogic to perform steps when the merchant participates in a reserve, thesteps comprising: computing a reserve adjustment amount; reducing thenet deposit amount by the reserve adjustment amount; transferring fundscorresponding to the reserve adjustment amount to a reserve for themerchant; and transferring funds corresponding to the reduced netdeposit amount to a merchant account for the merchant.
 19. The system ofclaim 7, further comprising: control logic to generate a new merchantinformation file from the respective default values and the input data,wherein during processing of monetary purchase card transactions for thenew merchant, the merchant-specific information is obtained by accessingthe new merchant information file.
 20. A system for providing purchasecard transaction processing services to a plurality of merchants,comprising: a data store having a merchant account record associatedwith each of the plurality of merchants, each merchant account recordincluding a plurality of fields for storing merchant-specificinformation, at least a portion of the merchant-specific informationrelating to merchant direct access authorization, wherein each merchantaccount record is associated with each of the plurality of merchantsusing a merchant financial account record system, the merchant financialaccount record system being managed at least in part by an entity whichprovides purchase card transaction processing services to the merchant;control logic configured to process, using the merchant financialaccount record system, a non-monetary transaction to update the merchantaccount record associated with the merchant, including: control logicconfigured to identify the merchant account record to be updated;control logic configured to receive input data including informationidentifying which of the plurality of fields is to be updated and newdata to be stored in the identified field, and a request for immediateupdating of the identified field; control logic configured to update theidentified field to store the new data, wherein updating the field isperformed substantially without delay upon receiving the request,wherein updating the identified field comprises rebuilding a virtualstorage access method associated with the merchant; and subsequentlyusing the merchant-specific information from the updated merchantaccount record to process a monetary purchase card transaction submittedby the merchant.